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Description 

[0001] The invention relates to the transmission of data. It is particularly, but not exclusively, related to the transmission 
of data to and from mobile terminals. This data may be obtained by using the Internet. 

5 [0002] With increased use of mobile cellular terminals, there is a growing demand for such terminals to send and 
receive data over wireless links. For this purpose a portable computer connected to a cellular telephone or from an 
integrated computer/cellular phone device may be used. One example of such data transmission is browsing the Internet. 
[0003] The term "Internet" is commonly used to describe information which can be accessed using a terminal, typically 
a PC, usually connected via a modem, to a telecommunications network. The content can be stored at many different 

10 sites remote from the accessing computer, although each of the remote sites is also linked to the telecommunications 
network. The content can be structured using Hypertext Mark-up Language (HTML). The Internet is made workable by 
the specification of a standard communications system which makes use of a number of protocols, such as the Transfer 
Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP), to control the flow of data 
around the numerous different components of the Internet. TCP and UDP are concerned with the transmission of Internet 

is data with different quality of service characteristics, such as in-order, reliable delivery of data, or unreliable delivery of 
independent data packets. IP is concerned with the structuring and routing of data. On top of that, other application 
specific protocols may be provided to manage and manipulate the various kinds of information available via the Internet, 
for example HTTP to access HTML content, FTP to access files or SMTP to access e-mail. 

[0004] The Internet is physically constructed from a hierarchy of telecommunications and data communications net- 

20 works, for example local area networks (LANs), regional telephone networks, and international telephone networks. 
These networks are connected internally and externally by so-called "routers" which receive data from a source host, 
or a previous router in a transmission chain, and route it to the destination hostorthe next router in the transmission chain. 
[0005] Obtaini ng access to the Internet generally involves having sessions between a terminal, such as a mobile 
terminal, and a server. A session is a series of interactions between a terminal and a server having a well-defined 

25 beginning and end and involving agreed-upon characteristics. Typically, a session involves a peer announcing to another 
peer a desire to establish a session, both peers negotiating the characteristics of the session, the peers engaging in a 
variety of transactions and one of the peers ending the session. The characteristics which are negotiated are typically 
the length of packets to be exchanged, the character sets which can be understood and manipulated and the versions 
of protocols which are to be used. 

30 [0006] As the demand for multimedia and other wireless services increases, the available wireless bandwidth is also 
increasing, and so the need to be able to provide the large data transfers wirelessly is also increasing. 
[0007] In order to provide standardisation of communication to and from mobile terminals, the Wireless Application 
Protocol (WAP) has been proposed. This is a set of industry-wide specifications suitable for developing applications and 
services to operate over wireless communications networks. WAP specifies an application framework and network 

35 protocols for wireless devices such as mobile telephones, pagers and personal digital assistants (PDAs). WAP is appli- 
cable to a number of different systems including GSM-900, GSM-1800, GSM-1900, CDMA IS-95, TDMA IS-136, wide- 
band IS-95 and third generation systems such as IMT-2000, UMTS and W-CDMA. 

[0008] WAP is described in documents WAP WTP Wireless Application Protocol Wireless Transaction Protocol Spec- 
ification (version 30 April 1998) and WAP White Paper, AV-System Radio, February 1999. 
40 [0009] WAP has architecture based on the following components or layers: 

An application layer (called the Wireless Application Environment or WAE) is a general-purpose application envi- 
ronment. Its purpose is to provide an interoperable environment which allows operators and service providers to 
provide applications and services to a variety of wireless platforms. 

45 

A session layer (called the Wireless Session Protocol or WSP) provides the application layer with a consistent 
interface for two session services. The first is a connection-orientated service that operates above a transaction 
layer protocol WTP (referred to below). The second is a connectionless service that operates above a secure or 
non-secure datagram service WDP (referred to below). 
50 Atransaction layer (called the Wireless Transaction Protocol orWTP) runs ontopof a datagram service that provides 

a light-weight transaction orientated protocol that is suitable for implementation in "thin" clients such as mobile 
terminals. WTP operates over secure or non-secure wireless datagram networks and provides the foil owing features: 

Three classes of transaction requests: 

55 

class 0 is for unreliable one way requests; 

class 1 is for reliable one-way requests; and 

class 2 is for reliable two-way request-reply transactions, 
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Optional user-to-user reliability in which the WTP user triggers the confirmation of each received message, 
Optional out-of-band data on acknowledgements, 

Protocol Data Unit (PDU) concatenation and delayed acknowledgements to reduce the number of messages 
sent, 

Asynchronous transactions. 

A security layer (called the Wireless Transport Layer Security or WTLS). This is based on the industry standard 
Transport Layer Security (TLS) protocol. It is optimised for use over narrow band communications channels. It 
includes data integrity, privacy, authentication and denial -of -service protection. Applications are able selectively 
to enable or disable WTLS features depending on their network requirements and the characteristics of the 
underlying network. 

A transport layer (called the Wireless Datagram Protocol or WDP). The WDP layer operates above the data capable 
bearer services supported by the various network types. As a general transport service, WDP offers a consistent 
service to the upper layer protocols of WAP and communicates transparently over one of the available bearer 
services. 

The layers are arranged in a protocol stack with each of the layers of the architecture being accessible by the layers 
above as well as by other services and application. These protocols are designed to operate over a variety of different 
bearer services. A specification describing this architecture and the protocol layers is available from http//www.wapfo- 
rum.org/. 

[0010] WAP is based upon transactions. Most transactions are either of the push type or of the pull (request-reply) 
type. In push type transactions a peer sends information which has not been specifically requested and in pull type 
transactions, a peer specifically requests to receive information from another peer. A pull type transaction can take the 
form of an Invoke transaction in WAP between a client (sender) and a server (receiver). Such a transaction involves the 
client sending a request (Invoke) to the server and the server returning a response (Result) which includes data according 
to the request. The client and the server both have WAP protocol stacks and the request and the response are effected 
by means of service primitives invoked between layers in each of the stacks so that messages in the form of protocol 
data units flow between the client and the server over a suitable bearer layer. Service primitives represent the logical 
exchange of information and control between a protocol layer and another entity using it, such as between the session 
layer and the application environment (WAE). They consist of commands and their respective responses associated 
with the particular service provided. Invoking a service primitive in a peer on one side of a communication link results 
in an event being generated in a peer in the other side of the link. 

[001 1] In this description the term messages is used to refer both to service primitives and to PDUs. A message is a 
logical abstraction of a service data unit (SDU) appearing in a service primitive request so that it appears on a peer side 
as an SDU in a service primitive indication. In the present case the SDU is the user data field in service primitives. 
[0012] If any of the messages have a length which exceeds the maximum transfer unit (MTU) size of the bearer 
services, that is the maximum size of a single packet as specified by a particular bearer, then before the message is 
sent, it is segmented into a sequence of packets in the WTP layer. The packets are transmitted individually or in groups, 
and then re-assembled once they have been received. This process is referred to as segmentation and re-assembly 
(SAR). SAR assigns consecutive sequence numbers to segmented data packets so that their order can be re-created 
on re-assembly. In WAP the maximum size of a segmented message is 256 packets. Since each packet has a maximum 
size of 1 to 2 Kbytes (typically 1.5 Kbytes), the maximum size of a message is typically less than 0.5 Mbytes. 
[001 3] When the data packets are received and the message is re-assembled by the WTP, the re-assembled message 
is then passed on to a WTP user, that is the WSP or an application directly above the WTP. However, since the WTP 
only provides the re-assembled message to the upper level once all of the segmented data packets have arrived, this 
means that the sender and the receiver have to use data buffers equal to the maximum size of the message. 
[001 4] The units of data transfer are the PDUs. A PDU comprises an integer number of octets and consists of a header 
(comprising a fixed part and a variable part) and data (if any is present). The fixed part contains information which is 
necessary for consistent and satisfactory communication. The variable part, which needs to be attached only to the fixed 
part, contains optional information which is not absolutely necessary. The fixed part of the header contains frequently 
used parameters and a code identifying a particular PDU. The length and the structure of the fixed part are defined by 
the PDU code. Commonly used PDUs include Invoke, Result, Acknowledge and Abort. Commonly used PDU codes in 
WAP are defined in the Wireless Transaction Protocol Specification. 
[0015] The parameters of the fixed part of a PDU header include: 

The Continue flag (CON) which indicates the presence of any Transport Information Items (TPIs) in the variable part. 
The Group Trailer (GTR) flag which indicates the last packet of a transmission group (the GTR packet). 
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The Transmission Trailer (TTR) flag which indicates the last packet of the segmented message (the TTR packet). 
The Packet Sequence Number (PSN) which is used for numbering segmented messages and data packets. It 
indicates the position of the data packet inside a sequenced data flow. The length of this parameter is 8 bits. 
The re -transmission indicator (RID) which enables the receiver to differentiate between packets duplicated by the 
5 network and packets re-transmitted by the sender. 

The Transaction Identifier (TID) which is used to associate a packet with a particular transaction. 

The Transaction Class (TCL) which indicates the desired transaction class in the invoke message. It is chosen by 

the initiator. 

The TID new flag which is set when the initiator has "wrapped" the TID value, that is when the range of TID values 
10 has been fully incremented so that the next TID value re-starts at the lower end of its range and is therefore lower 

than the previous TID value. 

The U/P flag which, when set, indicates that an initiator requires a user acknowledgement from the server WTP 
user. It causes the WTP user to confirm every received message. 

The parameter Number of Missing Packets which indicates the number of packets missed during the reception of 
is the current group. If this parameter has zero value, all packets in the group are missed, otherwise afterthis parameter 

the packet number of the missing packet(s) are listed. 

The parameter PSN(s) of Missing Packet(s) which is a list of packet sequence numbers for the missing packets, 
the re-transmission of which is requested. 

20 [0016] The variable part of the PDU header is used to define less frequently used parameters. Variable parameters 
are carried in Transport Information Items (TPIs). These can be used for a number of purposes such as indicating to 
the peer the maximum group size and the group delay. 

[0017] Data buffers in the terminal and in the server need to be large enough to hold transmitted data. In the WAP 
standard one message is sent inside a transaction by a sender to a receiver. If the data is in a single block, for example 
25 a message 1 00 KB long, the receiver needs a 1 00 KB data buffer to store the whole message. However, certain messages 
do not have to be stored and so a data buffer is not necessary for the purpose of the message. This is the case for the 
data stream from a video telephone; it does not have to be stored since it can be sent directly to a video display to be 
displayed. 

[0018] TCP is used to transmit large amounts of data in wired networks. However, it is not particularly suitable for 
so wireless networks. It requires a connection set-up having a round-trip. It starts a transaction slowly. It has cumulative 
acknowledgements in case of packet loss, which occurs often in wireless environments. These cumulative acknowl- 
edgements are undesirable because they generate too much data traffic. In wired networks, if packets are lost, this is 
generally due to congestion of routers. To deal with this, the data transmission rate by the sender is reduced and so 
data transmission takes more time. In wireless networks packet loss is common and may be due to a number of factors 
35 unrelated to congestion, such as cell hand-over or errors caused in the wireless link. Therefore, packet loss does not 
necessarily provide a reason for the transmission rate to be reduced. 

[0019] According to a first aspect of the invention there is provided a method of carrying out a transaction in accordance 
with claim 1 . 

[0020] Of course, where it is stated that the receiver acknowledges receipt of data packets, it may be that in certain 
40 circumstances, the data packets may not actually be received. In such circumstances, the receiver may notify the sender 
that a packet or packets have not been received. 
[0021] Preferably the link is a wireless link. 

[0022] Preferably the message is not of predetermined length. In this context, "predetermined" means that the receiver 
knows how many messages or how many packets may be received before they have been received. I n one embodiment 

45 of the invention, the data may only comprise one message. 

[0023] In this context, "reliable" means acknowledged so that the sender knows that the message has been received 
by the receiver. By providing a sequence of reliable data packets, transmission of the data message has the character 
of a data stream. Since individual packets are reliably received, then it is not necessary to provide a large buffer to 
contain the whole of an arbitrarily long message. In the case of a videoconference transmission, this could be a huge 

50 amount of data and so would require a huge buffer. 

[0024] In one embodiment the invention uses many features of the WAP standard and architecture and is backward 
compatible with WAP even though it expands the amount of transaction data. The invention provides more efficient 
transfer of large amounts of data than is possible in using sequential individual transactions. It enables transmission of 
an arbitrarily long sized stream-like sequence of messages inside a transaction. 

55 [0025] Preferably the invention is used within the WAP standard. It may form the basis of a new transaction class 
which has one reliable Invoke message and one reliable Result message. The Invoke and Result messages are condi- 
tionally expanded with reliable data messages thus providing for transmission of a large amount of data. 
[0026] Preferably in there can be more than one transaction outstanding at any one time. Preferably there can be a 
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number of asynchronous transactions existing in a single session. 

[0027] Preferably the packets are sent in groups of packets. The receiver may acknowledge a complete group when 
all packets from the group have been received. This may occur by the receiver acknowledging the last packet of a group 
when it has confirmed that the other packets of the group have been received. In this way, packets other than the last 

5 packet are implicitly acknowledged by acknowledgement of the group. 

[0028] Preferably, during transfer of the data message, the data packets are numbered consecutively. A segmentation 
and re-assembly technique such as SAR may be used. However, segmentation may not be used. Preferably thesequence 
of data packets is ordered by PSN. This may also enable missing packets to be identified. The arbitrary length of the 
data message may be provided by having PSNs which wrap around. 

w [0029] Preferably communication between the sender and the receiver is bi-directional within the transaction. There 
may be two channels provided one for transmitting data from an initiator to a responder and the other for transmitting 
data in the opposite direction. By providing two channels, the invention provides full-duplex reliable transaction service. 
Preferably each of the channels is closed by sending the last message of the data. One WSP session may comprise 
several transactions of this type. The invention allows for interactive communication. 

15 [0030] The transaction may be started by an Invoke command. Once started, it may be continued by Stream Data 
commands. Data messages according to the invention may be transmitted either by the initiator or responder of a 
transaction. Preferably data transmission over one channel is terminated when the sender sends a DataEnd TPI and it 
is received by the receiver. If transmission over both channels is terminated the transaction may be terminated. 
[0031] According to a second aspect of the invention there is provided a mobile terminal for transmitting data in 

20 accordance with claim 31 . 

[0032] According to a third aspect of the invention there is provided a gateway for transmitting data in accordance 
with claim 32. 

[0033] According to a fourth aspect of the invention there is provided a data transmission system in accordance with 
claim 33. 

25 [0034] According to a fifth aspect of the invention there is provided a data transmission system in accordance with 
claim 34. 

[0035] According to a sixth aspect of the invention there is provided a computer program product stored on a computer 
readable medium in accordance with claim 35. 

[0036] According to a seventh aspect of the invention there is provided a method of carrying out a transaction over a 
so link between and a sender and a receiver to transmit data which is not of predetermined length in the form of a plurality 
of data packets, the method comprising the steps of: 

applying a packet sequence number to the packets the packet sequence number having a range from a first end 
defined by a first packet sequence number to a second end defined by a last packet sequence number; 
35 wrapping the packet sequence number around when it reaches one of the ends of its range. 

[0037] Although it is preferred that the packet sequence number is consecutive for each packet, it may increase or 
decrease from one packet to a following packet. It may change in steps of one from one packet to a following packet or 
it may change in steps other than of one, two for example, or some other integer. 
40 [0038] An embodiment of the invention will now be described by example only with reference to the accompanying 
drawings in which: 

Figure 1 shows a transaction in which segmentation is used; 

Figure 2 shows the structure of a message; 
45 Figure 3 shows a transaction in which segmentation is not used; 

Figure 4 shows another view of the transaction of Figure 3; 

Figure 5 shows a table of valid service primitive sequences; 

Figure 6 shows a communication system; 

Figure 7 shows a gateway; 
50 Figure 8 shows a mobile terminal; and 

Figure 9 shows the system according to Figure 6 in a different form. 

[0039] In one embodiment, the invention provides a new transaction class for the WAP standard that enables data of 
an arbitrarily long length to be transmitted. This new class is class 3. Such data may a data stream originating from a 
55 videoconference, it may be a multi-media stream or it may be a download of software. 

[0040] Aclass 3 transaction will now be described. Thefollowing service primitives are used during aclass 3transaction: 

TR-Stream Invoke; 



5 



EP 1 764 966 A1 



TR-Stream Result; 
TR-Stream Invoke Data; 
TR-Stream Result Data; and 
TR-Abort. 

5 

A prefix of TR- signifies that a service primitive is being used between layers in a protocol stack. A prefix of S- indicates 
that a service primitive is being used in a session layer (such as WSP). 

[0041] In the following description, a service primitive describes the request to the WTP from either an upper or a 
lower local layer. This results in a PDU being generated which is a coded packet (containing a header and data), which 

10 is sent through the network during the transaction. 

[0042] Figure 1 shows part of a class 3 transaction in which data is transmitted. The transaction is initiated by one 
communicating entity, referred to as an initiator, with another communicating entity, referred to as a responder. The 
initiator and the responder communicate over two channels, each channel having a sender and a receiver depending 
on the direction of data flow. There is an input channel and an output channel; the input channel is established by the 

is initiator for its data flow and the output channel is established by the responder for its data flow. Since there are two 
channels, the initiator and the responder each act as both a sender and as a receiver of data. The term "channel" refers 
to a stream-like data path for transmitting an ordered sequence of messages in one direction. The term does not refer 
to a physical entity but refers to the logical operations which provide this result. 

[0043] The WTP user can be either the WSP or it can be the application communicating directly with the WTP over 
20 a connection. In the former case each transaction is accomplished in the context of a session. In the latter case the WSP 
and the WSP user are simply on the same address quadruplet. 

[0044] Figure 1 only shows messages being transmitted over an input channel from the initiator (sender) to the re- 
sponder (receiver). Messages transmitted on the output channel, particularly results of data being transmitted by the 
responder back to the initiator, are not shown. In any one channel acknowledgements of data flow in the opposite 
25 direction to the data. 

[0045] Before describing the transaction of Figure 1 in detail, it will be described in simple terms in order to illustrate 
how it proceeds. A Stream Invoke message is sent on the input channel. The responder responds on the output channel 
with a Stream Result message. Both messages may then be followed by additional Stream Data messages, which are 
considered to be continuations of the original message and which carry additional data. Packets in the additional data 
so messages are given consecutive PSNs so that the receiver of the data messages is able to order the data messages 
correctly when they are received. Either channel in the transaction can be terminated by an End-Of-Data message. The 
transaction is terminated if both the initiator and the responder receive End-Of-Data messages. All messages are ac- 
knowledged. A message may comprise an individual packet or may be segmented into a number of packets. 
[0046] The PDUs used in class 3 have the following codes: 

35 



PDU type 


PDU Code 


Invoke 


0x01 


Result 


0x02 


Acknowledgement 


0x03 


Abort 


0x04 


Segmented Stream Invoke 


0x08 


Segmented Stream Result 


0x09 


Stream Negative Acknowledgement 


OxOA 



[0047] The format of the fixed header structure of the PDU in the invention is the same as is used in the WAP standard. 
so The use and operation of the PDUs are described below. 

[0048] During the transaction, service primitives are invoked between a provider layer and a user layer in a WAP 
protocol stack in each of the initiator and the responder. The particular parameters which can be invoked by a service 
primitive are selected from the following: 

55 The source address. This is the unique address of the device making a request to the WTP layer. It may be an 

MSISDN number, IP address, X.25 address or other identifier. 
The source port number. This is associated with the source address. 

The destination address. This is the address of the user data submitted to the WTP layer. The destination address 
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may be an MSISDN number, IP address, X.25 address or other identifier. 

The destination port number. This is associated with the destination address for the requested or an existing trans- 
action. 

5 [0Q49] The user data. This is carried by the message generated from the primitive being invoked. The unit of data 
submitted to or received from the WTP layer, that is the SDU. This is the complete unit (message) of data which the 
higher layer has submitted to the WTP layer for transmission. The WTP layer transmits the Datagram SDU and delivers 
it to its destination without any manipulation of its contents. 

End-Of-Data. This is used to indicate that a particular SDU carries the last part of the user data which will be sent to a 
10 responder in a transaction. 

The transaction handle. This is an index returned to a higher layer so that it can identify the transaction and associate 
data received with an active transaction. The transaction handle uniquely identifies a transaction. It is an alias for the 
source address, source port, destination address and destination port of the transaction. The transaction handle has 
local significance only. 

is Exit info. Additional user data to be sent to the originator of the sequence of messages on its completion. This is only 
present in TR-Stream- Result and TR-Stream- Result-Data service primitives. 

[0050] Referring back now to Figure 1, the transaction will now be described in terms of the sequence of service 
primitives occurring in the protocol stacks of the initiator and the responder and the PDUs passing between them. A new 
class 3 transaction is initiated in the initiator by a layer above the WTP layer (referred to as the WTP user (initiator)), 
20 such as the WAE or the WSP, invoking the TR-Stream Invoke request service primitive in the WTP layer (referred to as 
the WTP provider (initiator)). When the new transaction is invoked, the initiator increments the Transaction Identifier 
(TID) by one to indicate that it is a new transaction. Within a particular class 3 transaction all messages (including all 
PDUs) carry the same TID. 

[0051] Invoking the TR-Stream Invoke request service primitive invokes parameters in the WTP provider (initiator) 
25 which are required to set up the transaction. The user data is also included. The parameters included in the TR-Stream 
Invoke service primitive are shown in the following table: 



35 



Primitive 

Parameter 


TR-Stream Invoke 


req 


ind 


res 


cnf 


Source Address 


M 


M(=) 






Source Port 


M 


M(=) 






Destination Address 


M 


M(=) 






Destination Port 


M 


M(=) 






Ack-Type 


M 


M(=) 






User-Data 


O 


C(=) 






End-Of-Data 


M 


C(=) 






Handle 


M 


M(=) 


M 


M 



[0052] In this table and the tables below, the legends M, O and C have the following meanings: 

45 

M means that a parameter is mandatory and must be present; 

O means that a parameter is optional and may be omitted; and 

C means that a parameter is conditional depending on the values of other parameters. 



[0053] The Stream Invoke service primitive receives the Invoke PDU header and then the WTP provider (initiator) 
sends the Invoke PDU with an implicit packet number of zero. The Invoke PDU is always the first message of the 
transaction. It contains the TCL parameter. The available transaction classes are given below: 



55 



Class 


TCL 


0 


0x00 


1 


0x01 
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(continued) 



Class 


TCL 


2 


0x02 


3 


0x03 



[0054] In this case the PDU header indicates that the transaction is of class 3. The first time a PDU is transmitted the 
re-transmission indicator (RID) field in the header is clear. It should be noted that the TCL to identify a class 3 transaction 
only requires two bits like the TCLs for classes 0, 1 and 2 and is thus backward compatible with the WAP standard. If 
the responder does not support class 3 transactions, the transaction is aborted by the responder. 
[0055] When an Invoke PDU is received, the WTP provider (responder) checks the TID and determines whether a 
verification has to be initiated. If so, the WTP provider (responder) starts a TID verification procedure. If not, it delivers 
the message to the WTP user (responder). The Acknowledgement PDU, Ack PDU, is used in the TID verification process 
of class 3 transactions. 

[0056] The structure of the message will now be described with reference an example shown in Figure 2. If the Stream 
Invoke message size exceeds the MTU for the network, the message is segmented into an ordered sequence of packets. 
In this example, there is a stream invoke packet having a PSN of 0, a first set of packets having PSNs of 1 to 1 6 and a 
second set of packets having PSNs of 1 7 to 33. At the beginning of transmission of the message, the End-Of-Data flag 
in the Invoke service primitive in the initiator is cleared to indicate that further data packets are to be transmitted. If the 
End-Of-Data flag were not cleared, this would indicate that no further SDUs are to come. The GTR flag set in a packet 
indicates the end of a group. The TTR flag set in a packet indicates the end of an SDU. This may mark the division 
between two SDUs or the last SDU of the message. The DataEnd TPI is attached to the last packet of the last SDU. 
[0057] The first packet generated from an Invoke message always carries the Invoke PDU header and it is assumed 
as having implicit PSN zero (as is shown in Figure 2). If the Stream Invoke message is segmented the responder regards 
the Invoke PDU as packet number zero and waits for the following Segmented Stream Invoke PDUs. Additional packets 
are provided with a Segmented Stream Invoke header having sequentially increasing PSNs. In Figure 2 packets 1 to 
33 comprise this type of PDU. Such a PDU is as follows: 



Bit/Octet 


0 


12 3 4 


5 


6 


7 


1 


CON 


PDU Type = Segmented Stream Invoke 


GTR 


TTR 


RID 


2 
3 


TID 


4 
5 
6 
7 


PSN 



[0058] The packets are transmitted in groups. Group transmission is discussed in further detail later. The packets are 
acknowledged in groups. 

[0059] Irrespective of whether the Stream Invoke PDU is segmented, in class 3 transactions the PSN is kept both by 
the initiator and the responder. This is in order that the sender knows the next PSN (the PSN of the next packet) and 
that the receiver knows the PSN of the last acknowledged packet and thus knows the next expected packet (which is 
not necessarily the next received packet). If in the Stream Invoke service primitive the End-Of-Data flag is set, the 
message handler attaches a DataEnd TPI to the fixed part of the header of the PDU. If the Stream Invoke message is 
not segmented, its Invoke PDU carries the DataEnd TPI . If the Stream Invoke message is segmented the last segmented 
packet of the last message group carries the DataEnd TPI and the channel is closed. 

[0060] The PSN wraps around and has a 32 bit field. This is in order to provide a greater time for data transmission 
so that there is a high probability that all packets in a data stream will have been received before the PSN has wrapped 
around completely and PSN numbers are re-used. The transaction may be long lived, so only the PSN (or occasionally 
the RID) will differentiate a new valid packet from duplicates of old packets. 

[0061] The WTP provider (initiator) sends the Invoke PDU, starts a re-transmission timer and sets the re-transmission 
counter is set to zero. In addition, the WTP provider (initiator) initialises the PSN to zero and starts waiting for an 
acknowledgement from the WTP provider (responder). When the WTP provider (responder) receives the Invoke PDU 
with a valid TID, it acknowledges the Invoke message and delivers it to the WTP user (responder) by generating the 
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TR-Stream Invoke indication service primitive. 

[0062] If an acknowledgement of the Invoke PDU or any other packet has not been received by the sender when the 
re-transmission timer expires, that is the re-transmission interval has been reached, the re-transmission counter is 
incremented by one, the last packet of the group is re-transmitted and the re-transmission timer is re-started. For all re- 
5 transmissions the RID field is set. It is the only field which is changed. The WTP provider continues to re-transmit until 
the number of re-transmissions has exceeded the maximum re-transmission value. If no acknowledgement has been 
received by the time that the re-transmission counter is fully incremented and the timer expires, the transaction is 
terminated and the local WTP user is informed. 

[0063] Assuming that the WTP provider (responder) receives the Invoke PDU, it acknowledges the first packet, that 
10 is the Invoke PDU, with a Stream Acknowledgement PDU, Stream Ack PDU. This is an Ack PDU carrying the Stream 
PSN TPI header with the PSN equal to 0. The WTP provider (responder) also sends its maximum group size in the form 
of an Option TPI (MaxGroupSize TPI) to indicate for the sender a group size window which is permitted. The group size 
is chosen by the sender so that it can fit the current network load and not be larger than the receiver window. The last 
window is valid until the next change of the window performed by the receiver appending a MaxGroupSize TPI to the 
is acknowledgement of the last group. The receiver should choose a group size which is not too large for the optimal 
reaction for the network and load changes. 

[0064] If the whole Stream Invoke message can be transmitted from the initiator to the responder in one datagram 
and so does not need to be segmented and re-assembled, it is sent as an Invoke PDU. This PDU is re-used even though 
there is no segmentation in order to minimise the number of PDUs which are required. Therefore, to indicate that it is 
20 last packet in a message, the TTR flag is set to 1 in its header. 

[0065] The packets are sent and acknowledged in groups. If there is no need for segmentation to occur, a group will 
consist of a single packet. The packets in a packet group are sent in a single batch. Since the first group is sent without 
knowing the status of the receiver the number of packets should be one. Two alternative embodiments of a package 
transmission method are described below. 

25 

Transmission Method 1 

[0066] This embodiment of the transmission method is not stop-and-wait. This means that there can be outstanding 
packet groups in that packets of a subsequent group may be sent before an acknowledgement has been received for 
so a previous group. 

[0067] The last packet of the group is the GTR packet. The GTR flag means that the sender requests an acknowl- 
edgement for all the packets sent in that group. The last packet of the entire message is the TTR packet. 
[0068] In transmission method 1, if the GTR flag is set, the receiver has to send an acknowledgement (Ack PDU 
carrying the stream PSN TPI) having the PSN of the last packet of the last complete group received or a Stream Nack 
35 PDU with the list of PSNs between the last group which has been acknowledged and last packet which has been received. 
The Stream Nack PDU contains the PSNs of missing packets from the most recent group and may also contain PSNs 
of missing packets from earlier groups up to, but not including, the last group which has been acknowledged. 



GTR 


TTR 


Description 


0 


0 


This packet is not a last packet 


0 


1 


This packet is the last of the message and an end of a group. Send acknowledgement. 


1 


0 


Send acknowledgement (this packet is the end of a group) 


1 


1 


Reserved. 



[0069] Each last packet of a message (SDU) is an end of a group and is to be acknowledged. TTR is also a request 
for an acknowledgement. 

[0070] The PSN included in the Stream PSN TPI is the PSN of the acknowledged packet (GTR packet). This acknowl- 
edgement is cumulative inside the group in that it acknowledges that all packets in the group arrived but does not mean 
that all other previous packets outside in this group received. 

[0071] Messages are sent in order. Transmission of a new message is not started before transmission of a previous 
message has ended. When the receiver receives a packet which is not a GTR packet, it stores the packet and waits for 
a new packet. When the receiver has received all packets of a message (that is the last packet is the TTR packet), it 
should be able to re-assemble the complete message. When the receiver receives the GTR packet, it checks whether 
it has received all packets belonging to that packet group. If this is the case, the receiver sends a Stream Ack PDU 
(carrying Stream PSN TPI in which PSN is set equal to the PSN of the GTR packet) to the sender. When the GTR packet 
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set has been received and one or more packets of the group are missing, the WTP provider waits for a period of time, 
such as half of the median round-trip, before returning the Stream Nack PDU with a list of the missing packets. If the 
status of the group changes during the time, that is one of the missing packets is, in fact, received, the waiting time is 
reset. The Stream Nack PDU is used exclusively in class 3 transaction for indication of erroneous reception of the group 
data. It is shown below: 
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[0072] The Stream Nack PDU may list other missing packets belonging to other groups. In this way, if a current Stream 
Nack PDU is received but a previous Stream Nack PDU has been lost, it is not necessary for the sender to have to re- 
transmit the last unacknowledged GTR packet and wait for the receiver to re-transmit the previously lost Stream Nack 
PDU. This can be explained as follows. Suppose that there are some missing packets in a first group and some missing 
packets in a second group. The receiver sends a first Stream Nack PDU for the first group and a second Stream Nack 
PDU for the second group. If the first Stream Nack PDU is lost, the sender does not know what is the status of the first 
group. Therefore, if the missing packets of the first group are included in the second Stream Nack PDU, this avoids the 
need for a full round-trip and associated re-transmission time. The sender re-transmits the missing packets with the 
original PSN but with the RID flag set. When the receiver has received the complete packet group, including those that 
were re-transmitted, it acknowledges the GTR packet. 

[0073] The size of the first group may be a default dependent on the bearer. In the Stream Ack PDU, following 
transmission of the first packet group, the receiver may send its MaxGroupSize to indicate its current window packet 
space. A window packet space is defined which is the number of packets which can be outstanding at any one time. 
This window packet space is present in both the sender and in the receiver. 

[0074] After this initial procedure the receiver can control the data flow with its window packet space. One way in 
which this is done is to change the group size during transmission of a single message. The available window packet 
space is measured in bytes. The maximum number of packets in one group is determined by the maximum bearer packet 
size. The maximum number of transmittable packets in a group is determined by the number of available data buffers 
at the receiver. 

[0075] The window packet space is mapped into a PSN space, that is a range of PSNs starting with the PSN of the 
longest outstanding packet (that is the packet that has been non-acknowledged for the longest time) and extending to 
a PSN equal to the PSN of the longest outstanding packet plus the number of packets in the window packet space. If a 
particular group is acknowledged, although this means that all packets belonging to that particular group have been 
received, it does not necessarily mean that packets in groups transmitted either before or after that particular group have 
been received. If a group acknowledgement arrives, and all other packets in the receiver PSN space having PSNs less 
than its PSN have been received, the window is adjusted so that it begins at the new longest outstanding packet in order 
to re-define the PSN space. In this way the PSN space can move incrementally, even by its beginning and end PSNs 
moving by one, rather than moving in jumps corresponding to the window packet space. 

[0076] As packets are sent by the sender and received by the receiver, delays in packet transmission may lead to 
outstanding packets. Assuming that these outstanding packets are received, as each longest outstanding packet is 
received, the receiver sends an acknowledgement to the sender of receipt of the longest outstanding packet and moves 
its window packet space to occupy the next PSN space. The PSN space thus now begins at the new longest outstanding 
packet. When the sender receives the acknowledgement, it moves its window packet space correspondingly so that the 
window packet spaces of the sender and of the receiver correspond. 

[0077] The sender should not create a group having larger number of packets than the window packet space. 
[0078] If the sender has not received an acknowledgement when the re-transmission timer expires, only the GTR 
packet is re-transmitted, rather than the entire packet group. 

[0079] If in the Stream Nack PDU the Number of Missing Packets parameter has value zero, all packets in the group 
have to be re -transmitted. 

[0080] The receiver may close its window by sending MaxGroupSize TP I equal to 0 with an acknowledgement because 
it has no more buffer space to receive data. However, the receiver still has to reserve one packet buffer to receive a 
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possible Abort. In order to provoke the receiver into giving information concerning its window, the sender sends a one- 
packet group (a GTR packet) even though the window is closed. The receiver sends an acknowledgement in response 
indicating the current status of the window. The window may not still be closed. When the window becomes open again, 
the receiver repeats the acknowledgement of the last packet group. The acknowledgement carries the MaxGroupSize 
TPI with the new available window size (perhaps other than 0). However, the sender may not receive the acknowledge- 
ment regarding the open window. This may be because the acknowledgement has been lost, it has been sent but not 
yet received or it has not yet even been sent. If the sender does not receive an acknowledgement, a re-transmission 
timer is used in a conventional way to control any re-transmissions which are necessary. In any case, sender is informed 
about resource problems in the receiver and so the re-transmission timer is larger than normal. 

Transmission Method 2 

[0081] This embodiment of the transmission method is stop-and-wait. This means that there cannot be outstanding 
packet groups. The GTR packet for a subsequent group is only sent when an acknowledgement has been received for 
all of the packets of a previous group. Details of the scheme for shifting along the window packet space on acknowl- 
edgements being received corresponds to that described above. 

[0082] The last packet of a group is the GTR packet. The last packet of the last packet group of an entire message is 
the TTR packet. In transmission method 2 the GTR and the TTR flags have the same meanings as are described in the 
WAP Wireless Transaction Protocol Specification. 

[0083] When the receiver receives a packet which is neither a GTR packet nor a TTR packet, it stores the packet and 
waits for a new one. When the receiver has received a complete packet group and the last packet is a TTR packet, it 
should be able to re-assemble the complete message. When the receiver receives either a GTR or a TTR packet, and 
all packets in the group have been received successfully, it sends an Ack PDU (carrying Stream PSN TPI) to the sender. 
When either a GTR or a TTR packet has been received and one or more packets of the group are missing, the WTP 
provider waits a period of time, such as half the median round-trip, before returning the Stream Nack PDU with details 
of the missing packets. If the status of the group changes during the time, that is one of the missing packets is, in fact, 
received, the waiting time is reset. 

[0084] When the receiver receives either a GTR or a TTR packet, it checks whether it has received all packets belonging 
to that packet group. If the complete packet group has been received the receiver returns a Stream Ack PDU with the 
attached Stream PSN TPI header in which PSN is equal to the packet sequence number of the GTR or the TTR packet. 
The PSN included in the Stream PSN TPI is the PSN of the acknowledged packet (GTR or TTR packet). This acknowl- 
edgement is cumulative, it acknowledges that all previously transmitted packets are received. 

[0085] If one or more packets are missing, the receiver answers with Stream Nack PDU, and the missing packets are 
listed in the Stream Nack PDU. The missing packets are re-transmitted with the original PSN but with the RID flag set. 
When the receiver has received the complete packet group, including those that were re -transmitted, it acknowledges 
the GTR or the TTR packet. 

[0086] If the sender has not received an acknowledgement when the re-transmission timer expires, only the GTR or 
the TTR packet is re -transmitted, rather than the entire packet group. 

[0087] If in the Stream Nack PDU the Number of Missing Packets parameter has value zero, all packets in the group 
are re-transmitted. 

[0088] For improving throughput in this transmission method the following features are included: 

1 . During transmission of a group, the receiver may send the Stream Nack PDU without waiting for the GTR or the 
TTR packet, if it identifies that it missed some packets in the sequence. Therefore, if a first Stream Nack PDU 
concerning a particular packet is sent before the GTR or TTR packet has been received and the particular packet 
is still not received after the GTR or TTR packet has been received, then the particular packet will be indicated in 
a second Stream Nack PDU, and thus will be indicated as missing in both of the Stream Nack PDUs. 

2. The group size is chosen to be half of the numerical value of the group window size. In the case of the group 
window size being an odd number the group size is ((group window size)-1)/2. Determining the group size occurs 
by the receiver indicating its window size by the MaxGroupSize TPI and the sender selecting an appropriate group 
size. Operation of this transmission system will be demonstrated by the following example. Let us assume that the 
window size is 1 1 . Accordingly, the group size will be 5. There are four packets to be transmitted. In a first transmission 
burst, packets 0, 1 , 2, 3, 4 (GTR packet of first group), 5, 6, 7, and 8 are sent. This first transmission burst is the 
whole of the first group and part of the second group. The GTR packet of the second group is not sent in this 
transmission burst. In a second transmission burst, the first packet to be sent is the GTR packet of the second group 
followed by part of the third group. The GTR packet of the third group is not sent in this transmission burst. In 
subsequent transmission bursts, the first packet is the GTR packet of an old group from a preceding transmission 
burst and the packets of a new group excluding the GTR packet of the new group. As each 
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[0Q89] GTR packet is received, if all of the packets from its group have been received, an acknowledgement of that 
group is sent and the next transmission burst occurs. Only one GTR/TTR packet can be outstanding at any time. In 
providing this transmission method, the receiver needs to be able to store an incomplete sequence of packets from one 
group and a subsequent transmission burst and to re-assemble the groups. It is necessary for the receiver to be able 
to handle two packet groups having overlapping transmissions. Missing packets will be listed in a Stream Nack PDU 
and then re -transmitted. In the meantime, packets of the next group may already have been transmitted and may be 
waiting to be re-assembled in the receiver buffers. 

[0090] In this case of both transmission method 1 and transmission method 2, TTR implicitly marks the end of a group. 
[0091] After the message containing the DataEnd TPI has been acknowledged no more data messages can be sent 
to the receiver. 

[0092] The message is re-assembled in the WTP provider (responder). Once it has been re-assembled, the WTP 
provider (responder) invokes service primitive TR-Stream Invoke. ind in the WTP user (responder) and the WTP user 
receives the message and responds by invoking the service primitive TR-Stream Invoke. res in the WTP provider (re- 
sponder). 

[0093] In the class 2 transactions, a single Invoke message can be acknowledged by a single Result message without 
an Ack message being sent and received. This is implicit acknowledgement. In class 3 there may be many packets and 
many packet groups which relate to the same transaction and the transaction can proceed for a long time. Therefore, 
receipt of a Stream Result message does not implicitly acknowledge a particular Invoke message because it could relate 
to a number of different Invoke messages. This is because the Stream Result message does not contain the PSN or 
PSNs of the related Invoke message Furthermore, timing is important. The PDUs sent on a channel are not (necessarily) 
sent as an answer to each other. Individual acknowledgements are provided for individual packets, that is specific 
acknowledgements for GTR packets and implicit acknowledgements for non-GTR packets. 

[0094] User acknowledgementfunctionality is provided in class 3. When it is set (in the Stream Invoke service primitive 
by the WTP user and in the Invoke PDU by the WTP provider), all messages are not acknowledged by the receiving 
WTP provider automatically, but are sent to an upper layer to respond for the message. When the upper layer has 
responded, the WTP provider sends the acknowledgement to the WTP provider which sent the message. 
[0095] As mentioned above, Figure 1 only shows the messages being transmitted on the input channel during the 
transaction. In the output channel the transaction occurs in a similar manner. Afterthe responder has received the class 
3 Stream Invoke PDU, and acknowledged it, the Stream Invoke PDU is passed upwards to be dealt with by a layer or 
layers above the WTP provider (responder). A Result message is handled on the same way as the Invoke message. 
Upon assembling the data, the WTP user (responder) sends the Result message by initiating the TR-Stream Result 
request primitive in the WTP provider (responder). This TR-Stream Result primitive is used to send the result of a Stream 
Invoke message in a class 3 transaction. It has the parameters given in the table below: 



Primitive 
Parameter 


TR-Stream Result 


req 


ind 


res 


cnf 


User-Data 


O 


C(=) 






End-Of-Data 


M 


C(=) 


O 




Exit info 






O 


C(=) 


Handle 


M 


M 


M 


M 



[0096] The Result message is transmitted to the initiator using Result PDU. Depending on its size it is either segmented 
or it is not. When the Result PDU has been sent, the responder starts a re-transmission timer and waits for acknowl- 
edgement from the initiator. Afterthe Result PDU is received by the initiator, the WTP provider (initiator) forwards up 
the TR-Result indication primitive to the WTP user (initiator). 

[0097] After the message containing the DataEnd TPI is acknowledged the transaction ends. 
[0098] After the last acknowledgement is sent by the receiver of the last group of the last message, the sender and 
the receiver both have to wait before clearing their respective administrations concerning the channel. This is so that 
the sender can re-transmit the last group if it does not receive an acknowledgement and the receiver can know that the 
sender received the acknowledgement. 

[0099] Figure 4 shows part of a class 3 transaction in which data is transmitted in expanded form. In common with 
Figure 1 , only communication over the input channel is shown. Figure 4 shows initiation of a class 3 transaction in which 
the Stream Invoke message size does not exceed the MTU for the network and segmentation is not used. The WTP 
user (responder) invokes the service primitive TR-Stream Invoke. req in the WTP provider (responder). If the End-Of- 
Data parameter is not set in the TR-Stream I nvoke request primitive, the initiator must issue at least one more TR-Stream 
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Invoke Data service primitive. These are discussed below. Since the message is not segmented into additional packets, 
the WTP provider (initiator) sends an Invoke PDU containing the whole message to the WTP provider (responder) and 
the WTP provider (responder) invokes a service primitive TR-Stream Invoke. ind in the WTP user (responder). When 
the WTP user (responder) has received the message, it invokes a service primitive TR-Stream Invoke. res in the WTP 
5 provider (responder). The WTP provider (responder) sends a Stream Ack having a PSN of 0 to the WTP provider (initiator) 
which results in the WTP provider (initiator) invoking a service primitive TR-Stream Invoke. cnf in the WTP user (initiator). 
The Stream Ack carries the MaxGroupSize TPI. 

[0100] In the case of Figure 3, the initiatorthen decidesto send more datatothe responder within the same transaction. 
The WTP user (initiator) invokes a TR. 
10 [0101] Stream Invoke Data. req service primitive in the WTP provider (initiator) to send additional data. The parameters 
of the TR-Stream Invoke Data (Stream Invoke Data) service primitive are shown below. This primitive is used to continue 
the data of a Stream Invoke message in a class 3 transaction. 



Primitive 
Parameter 


TR-Stream Invoke Data 


req 


ind 


res 


cnf 


User-Data 


O 


C(=) 






End-Of-Data 


M 


C(=) 






Handle 


M 


M 


M 


M 



[0102] Again, the Stream Invoke message size does not exceed the MTU for the network and so the message is not 
segmented into additional packets. The WTP provider (initiator) sends a Segmented Stream Invoke PDU to the WTP 
provider (responder). This PDU has a PSN of 1 because it is the next packet in the transaction and the TTR flag is set 
to indicate that it is the last packet in this message and to indicate that an acknowledgement has been requested. The 
WTP provider (initiator) sends the DataEnd TPI attached to the fixed part of the header of the Segmented Stream I nvoke 
PDU to the WTP provider (responder). The WTP provider (responder) invokes a service primitive TR-Stream Invoke 
Data.ind in the WTP user (responder). 

[0103] The WTP user (responder) responds by invoking the service primitive TR-Stream Invoke Data.res in the WTP 
provider (responder) when it has received the Invoke message. The WTP provider (responder) sends a Stream Ack 
PDU with Stream PSN TPI attached having a PSN of 1 to the WTP provider (initiator). The WTP provider (initiator) 
invokes the service primitive TR-Stream Invoke Data.cnf in the WTP user (initiator). 

[0104] Once the initiator has no more data to send, the End-Of-Data flag is set in the TR-Stream Invoke Data service 
primitive. 

[0105] If the initiator sends several more data message started with TR-Stream Invoke Data service primitives, they 
will also be provided by the Segmented Stream Invoke header whether or not the message is segmented. If it is necessary, 
the message is segmented. The Segmented Stream Invoke PDU is used in every case when class 3 transaction additional 
data is sent to the responder after a Stream Invoke message. If there is no need for segmentation of the message, this 
PDU will be the last packet of a one-packet message group. 

[0106] In case of the last data message the DataEnd TPI is attached to the fixed part of the header of the last Segmented 
Stream Invoke PDU. The End-Of-Data parameter is included in the Stream Invoke and Stream Invoke Data service 
primitives when that message is the last message of the message stream. The service primitive parameter will be set, 
and therefore the local WTP will attach the DataEnd TPI to the last PDU of this last message. 

[0107] Once the responder has obtained data in response to the Invoke message, the WTP user (responder) sends 
a Result message by initiatingthe TR-Stream Result requestservice primitive in the WTP provider (responder). Depending 
on the nature of the Result message, it may either be sent as a single message or segmented. The first packet generated 
from a Stream Result message always carries the Result PDU header and it is assumed as having implicit packet number 
zero. If the Result message needs to be segmented, it is sent in additional Segmented Stream Result PDUs. 
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w [0108] If it is desired for the WTP user (responder) to send further blocks of data, this can be achieved by issuing TR- 
Stream Result Data service primitives. These cause a number of Stream Result Data messages to be sent. This TR- 
Stream Result Data service primitive is shown in the table below: 



Primitive 
Parameter 


TR-Stream Result Data 


req 


Ind 


res 


cnf 


User-Data 


O 


C(=) 






End-Of-Data 


M 


C(=) 






Exit info 






0 


C(=) 


Handle 


M 


M 


M 


M 



[0109] This service primitive generates a Segmented Stream Result PDU even if there is no need for the segmentation 
25 of the message. In this case, this PDU will be the first and last packet of the message and the TTR flag will be set. 

[0110] After posting a Stream Invoke or Stream Result message the PSN counter will not be cleared until the end of 
the data transmission. 

[01 1 1] During the transaction the initiator and the responder may each transmit a number of blocks of data as required 
using separate Stream Invoke Data and Stream Result Data messages until the transaction is ended. 

so [01 1 2] Once the responder has no more data to send, it closes its side of the transaction by setting the End-Of-Data 
parameter setting either in the TR-Stream Result or in the TR-Stream Result Data service primitives issued invoked by 
the WTP user (responder) in the WTP provider (responder) and sending the End-Of-Data message (message with 
attached DataEnd TPI header). If the End-Of-Data parameter is not set in the TR-Stream Result request primitive, the 
Responder has to issue at least one more TR-Stream Result Data service primitive. However ending of the channel by 

35 the responder is not necessarily the end of the transaction because the responder can receive additional data from the 
initiator until it receives the initiator's End-Of-Data message. The transaction is terminated if both the initiator and the 
responder send their End-Of-Data messages. In any case, a transaction can be aborted at any time by either of the 
parties invoking the Transaction Abort service primitive. This service primitive is defined in the Wireless Transaction 
Protocol Specification. 

40 [0113] The last Ack PDU is sent when the last message of the channel has been received. The sender of the acknowl- 
edgement must maintain state information in order to be able to handle a re-transmission of the previous group (for 
example if the acknowledgement becomes lost). The state information can be maintained by using a wait timer. 
[0114] The received and re-assembled message is transferred to a level above the WTP provider, that is to the WTP 
user or elsewhere, having a size equal to the sent message. 

45 [0115] Unlike the transaction classes, 1 and 2, defined by the WAP standard, in class 3 transactions, all messages 
are acknowledged by explicit Stream Ack PDUs to indicate thatthe particular message has been received. The expanded 
data transfer can be overlapped, that is the two channels can work in parallel, until the DataEnd TPI is received. In effect 
this means that Stream Invoke Data PDUs can go in one direction at the same time as Stream Result Data PDUs can 
go in the opposite direction. 

50 [0116] The WTP provider (initiator) is able to initiate multiple transactions before the result of an earlier transaction is 
received. The transactions can be handled asynchronously in which responses to later transactions are received before 
responses to earlier transactions. 

[0117] The variable part of a fixed header of a PDU can consist of one or several TPIs. The length of a TPI can be 2 
or 8 bits. 

55 
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(continued) 



TP I 


TPI Identity 


Comment 


Info 


0x01 




Option 


0x02 




Packet Sequence Number 


0x03 


Note 1 


DataEnd 


0x04 


Note 2 


Stream Packet Sequence Number 


0x05 


Note 2 


Note 1) This TPI is only applicable if the segmentation and re- 
assembly is used to segment and re-assemble a message. 
Note 2) This TPI is used only in class 3 transactions. 
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[01 1 8] The Error TPI is returned to the sender of an erroneous or unsupported TPI. The Info TPI is used to piggyback 
a small amount of data in the variable part of the PDU header, for example performance measurements or statistical 
data. The Option TPI is used to transfer parameters between two WTP entities. It should be noted that unlike the Wireless 
Transport Protocol Specification, either party in a transaction may give out the Maximum Group Option TPI in any Ack 
20 PDU at any time and it should be valid until the next same type of TPI or the end of the transaction. The DataEnd TPI 
may be attached to the following PDUs: 

Invoke PDU 
Result PDU 
25 Segmented Stream Invoke PDU 

Segmented Stream Result PDU 

[0119] The meaning of the DataEnd TPI is that there will not be any more data transmission from this direction to the 
other party of the transaction. Therefore, this is the last numbered packet from this direction. If the End-Of-Data flag 
30 parameter of any of theTR-Stream Invoke, TR-Stream Result, TR-Stream Invoke Data orTR-Stream Result Data service 
primitive is set, the last packet of the last message group will carry this DataEnd TPI. Its structure is as follows: 



Bit/Octet 


0 


1 


2 


3 


4 


5 


6 


7 


1 


CON 


TPI Identity = DataEnd 


0 


PTI Length = 0 



[0120] In Class 3 transactions, the Ack PDU does not have a Packet Sequence Number field and the Stream Packet 
Sequence Number TPI is used as an attachment to the variable part of the Ack PDU header. The TPI differs for the two 
transmission methods referred to above. In transmission method 1, the PSN included in the Ack PDU is the PSN of the 
acknowledged packet (GTR packet). This acknowledgement is cumulative inside the group; it acknowledges that all 
packets in the group arrived but does not indicate that all previous packets outside in this group have been received. In 
transmission method 2, the PSN included in the Ack PDU is the PSN of the acknowledged packet (GTR or TTR packet). 



Bit/Octet 


0 


1 


2 


3 


4 


5 


6 


7 


1 


CON 


TPI Identity = Stream Packet Sequence Number 


0 


PTI Length = 4 


2 
3 
4 
5 


Packet Sequence Number 



[0121] Figure 5 shows a table of valid primitive sequences. In any one column, the service primitives which heads the 
column may only be followed by the corresponding service primitives in the rows that are marked with an X. End-Of- 
Data indicates the flag set in the service primitive. This table shows only globally the allowed sequence of the primitives. 
[0122] The steps involved in using a class 3 transaction on the level of the WSP layer will now be described. Figure 
4 shows the Stream Invoke transaction of Figure 3 at a higher level so as to show the involvement of session layers in 
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a sender and in a receiver. Figure 4 shows the session layer service primitives invoked by a WSP user in a WSP provider 
in each of the sender and the receiver. 

[0123] The S-Stream Method Invoke primitive is used to request an operation to be executed by the server. It can be 
used only together with the S-Method Result service primitive. 



Primitive 

Parameter 


S-Stream Method Invoke 


req 


ind 


Res 


cnf 


Client Transaction Id 


M 






M(=) 


Server Transaction Id 




M 


M(=) 




Method 


M 


M(=) 






Request URI 


M 


M(=) 






Request Headers 


O 


C(=) 






Request Body 


C 


C(=) 






End-Of-Data 


M 


M(=) 




C(=) 



[0124] The End-Of-Data flag indicates whether there will be any more data (continuation of the Request Body). If it is 
set, this is all of the data which has been sent by the Stream Invoke message. 

[0125] The S-Stream Invoke Data service primitive is used to send the continuation of the Request Body of the started 
operational request to the server. It can be invoked only after a preceding S-Stream Method Invoke primitive has occurred 
having its End-Of-Data flag clear. 



Primitive 

Parameter 


S-Stream Invoke Data 


req 


ind 


res 


cnf 


Client Transaction Id 


M 






M(=) 


Server Transaction Id 




M 


M(=) 




Method 


M 


M(=) 






Request URI 


O 


0(=) 






Request Headers 


0 


C(=) 






Request Body 


C 


C(=) 






End-Of-Data 


M 


MH 







[0126] The End-Of-Data flag indicates whether there will be any more data (continuation of the Request Body). If it is 
set, this is the last data which has been sent. 

[0127] The S-Stream Result service primitive is used to return a response to an operational request. It can be invoked 
only after a preceding S-Stream Method Invoke primitive has occurred. 



Primitive 

Parameter 


S-Stream Result 


req 


ind 


res 


cnf 


Server Transaction Id 


M 






M(=) 


Client Transaction Id 




M 


M(=) 




Status 


M 


M(=) 






Response Headers 


O 


C(=) 






Response Body 


C 


C(=) 






Acknowledgement Headers 






OC 


P(=) 


End-Of-Data 


M 


M(=) 




C(=) 
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[0128] The End-Of-Data flag indicates whether there will be any more data (continuation of the Response Body). If it 
is set, this is the all of the data which has been sent in this Stream Result message. 

[0129] The S-Stream Result Data primitive is used to return additional response data to an operational request. It can 
be invoked only after a preceding S-Stream Invoke primitive has occurred. 

5 



Primitive 

Parameter 


S-Stream Result Data 


req 


ind 


res 


cnf 


Server Transaction Id 


M 






M(=) 


Client Transaction Id 




M 


M(=) 




Status 


M 


M(=) 






Response Headers 


O 


C(=) 






Response Body 


C 


C(=) 






Acknowledgement Headers 






OC 


P(=) 


End-Of-Data 


M 


M(=) 




C(=) 



[0130] The End-Of-Data flag indicates whether there will be any more data (continuation of the Response Body). If it 
is set, this is all of the data which has been sent. 

[0131] In the S-Stream Method Invoke facility, the following PDUs are used: Get, Post and Reply. These PDUs are 
defined in the WAP standard. 

[0132] An example of another transaction is a Stream Push transaction. This Stream Push transaction also utilises 

the class 3 WTP transaction but the server takes the role of the initiator. In contrast to the Stream Invoke transaction, 

the Stream Push transaction is one-way only. The server initiates the transaction and the client is the responder. Large 

amounts of data can be pushed in any of the forms of data stream discussed above. The responder channel will be 

closed automatically since only the server sends data to the client. 

[0133] Services primitives used in the Stream Push transaction are defined below: 

S-Stream Push 



Primitive 

Parameter 


S-Stream Push 


req 


ind 


res 


cnf 


Server Transaction Id 


M_ 






M(=) 


Client Transaction Id 




M 


M(=) 




Response Headers 


O 


C(=) 






Response Body 


C 


C(=) 






Acknowledgement Headers 






O 


P(=) 


End-Of-Data 


M 


M(=) 







S-Stream Push Data 



Primitive 

Parameter 


S-Stream Push Data 


req 


ind 


res 


cnf 


Server Transaction Id 


M 






M(=) 


Client Transaction Id 




M 


M(=) 




Response Headers 


O 


C(=) 






Response Body 


C 


C(=) 






Acknowledgement Headers 






0 


P(=) 


End-Of-Data 


M 


M(=) 
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[0134] In the S-Stream Push facility, the PDUs Confirmed push PDU as defined in the WAP standard is used. 
[0135] In orderto providethese optional facilities, Push, Confirmed push, Suspend and Resume and Acknowledgement 
headers, changes have to be made to WSP. In particular, two protocol options flags have to be added and two more 
capabilities, Maximum Outstanding Stream Method Request and Maximum Outstanding Stream Push Request are 
introduced. 

[0136] It is possible for the initiator to send a first Invoke message and then send a second Invoke message (that is 
a Stream Invoke message) before the first Invoke message has been received by the responder. The responder would 
note that the Invoke message it receives first would have a new TID but may not correctly start a transaction. In this 
case, the responder stores the second Invoke message rather than discarding it and waits for the Invoke message. 
[0137] Concatenation of several PDUs in class 3 transaction may also be provided. It uses the same rules as con- 
catenation for the other classes as defined by the WAP standard. 

[0138] The invention can be incorporated into a mobile terminal, a WAP protocol stack, a WAP server or a WAP gateway. 
[0139] Figure 6 shows a communication system comprising a plurality of mobile terminals 2 having access to the 
Internet 4. The mobile terminals transmit signals 6 which are received by and transmitted through a wireless network 8. 
The signals comprise wireless mark-up language (WML) and WAP commands according to WAP. WML is a tag-based 
display language providing navigational support, data input, hyperlinks, text and image presentation and forms. It is a 
browsing language similar to HMTL. Signals 10 received by the network 8 are routed to a proxy or gateway server 12. 
The server 1 2 translates WAP requests into HTTP requests and thus allows the mobile terminals 2 to request information 
from a web server 14 and thus browse the Internet 4. Information obtained from the web server 14 is encoded by the 
gateway into a suitable format and then transmitted by the wireless network to the mobile terminal 2 which requested 
it. The mobile terminal 2 processes and uses the information. If the web server 1 4 provides content in WAP/WML format, 
the server 1 2 can retrieve such content directly from the web server 1 4. However, if the web server provides content in 
WWW format (such as HTML), a filter may be used to translate the content from WWW format to WAP/WML format. 
[0140] Although Figure 6 shows information being obtained from the Internet, the gateway itself may contain the 
desired information. For example, the client may retrieve information from the file system of the gateway. 
[0141] Figure 7 shows a gateway server embodied in hardware such as a computer 20. The computer 20 has dynamic 
memory, processing power and memory to store all of the programs needed to implement the gateway server such as 
the application program, the protocol stacks and the operating system. The computer 20 comprises a user interface 
such as a keyboard 22 and a display (not shown) and a server program 24. The server program 24 has an application 
program 26 for processing events of the underlying protocol, such as handling a request to retrieve WML from a server, 
and protocol stacks such as a WAP protocol stack 28 and a HTTP protocol stack 30. The application program 26 controls 
flow of data, including commands, requests and information, between the computer and various networks including a 
telephone network 32, the Internet 34 and a data network and circuit switched data networks 35. The computer 20 
communicates with the Internet 34 through the HTTP protocol stack 30 and an interface 36. The computer 20 commu- 
nicates with the telephone network 34 and the data network 35 through interfaces 38 and 40. The server program 24 
also comprises an application 42 which converts between HTTP and WAP. SMS messaging may be provided via a data 
connection through appropriate hardware to the operator's network. 

[0142] Individual threads 44 present in the application program 26 and the WAP protocol stack 28 use processors 46 
in the computer 20 to carry out necessary processing tasks. Allocation of threads to processors is provided by threading 
services 48 present within the operating system 50 of the computer 20. 

[0143] The WAP stack is built on top of so-called bearers (which provide datagram services). These bearers can be, 
for example, SMS or CSD. The bearers have their own protocol and are implemented through protocol stack implemen- 
tations. 

[0144] Figure 8 shows an embodiment of a mobile terminal 60. The mobile terminal 60 comprises a central processing 
unit (CPU) 62, a transceiver 64, a memory 66 for storing content, a WAP micro-browser and associated protocols 68 to 
control the transfer of data over the transceiver 64, a display 70 and a memory 72 for telephony related functions of the 
mobile terminal. The operation of the transceiver 64 in making telephone calls is not described since this relates to 
conventional telephony activity of the mobile terminal 60. The CPU 62 controls the operation of the other elements. 
[0145] Figure 9 shows the communications system of Figure 6. It provides a different view showing details of the client 
(for example a mobile terminal, the gateway and a server, in this case a web server. 

[0146] In the following are suggested some of the applications of the invention that are available in an embodiment 
in which WAP is used with bi-directional message streaming. Of course, most of these applications can be implemented 
with the existing WAP stack if the class 3 functionality is implemented on the application level. 

[0147] In carrying out transactions involving data transfer, there are two main considerations: transmitting large 
amounts of data and ordering of the transactions. Transmitting a sequence of messages enables large amounts of data 
to be transferred continuously and also enables the transmission of ordered events. If multiple transactions are used, 
the order transmitting and receiving messages is not guaranteed and so this has to be controlled at the application level. 
Transmitting ordered events is important as many applications need small amounts of data to be transferred with events 
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that are posted first arriving first. 

[0148] The invention can be applied to video-conferencing. Such a video-conferencing system is provided having a 
number of the clients connected to a WAP enabled server acting as a distribution centre. Each client is connected to 
the server by a two-way stream for sending and receiving a stream of individual pictures or frames. Streaming is useful 

5 because the frame order is important and without streaming the application itself must reconstruct frame order. It is 
advantageous to combine video-conferencing with WAP. Advanced user interfaces can be provided as WML decks to 
select, convey information and to link conferences. The whole service can be provided a single WAP server. Another 
important application domain for WAP-based video services is a Bluetooth service where WAP could be used as a 
transport protocol for browsing/accessing video information. 

w [0149] In another embodiment, home devices or other devices are provided with mini WAP servers to make them 
accessible from WAP enabled clients. An example is a WAP enabled voice mail service that allows connections from a 
WAP browser to browse the status of messages and allow them to be listened to. A channel from the client to the server 
is used as a control channel to send commands and sound is streamed over a channel from the server to the client. 
Commands sent to the device may include skip message, delete message and so on. 

is [0150] In yet another embodiment, a remote control or a remote measurement system is provided in which a client 
connects to the central processing server providing measurement data coming in stream (such as real-time pressure 
data) and the controlling server sends back control or summary information in a stream. If the system is WAP enabled 
with stream support, it may be implemented in the form of a WAP server having WAP enabled clients. 
[0151] In still another embodiment, a server-based gaming system is provided. In such a multi-player game system 

20 a centralised game server is provided to which clients connect. In the case of real-time action games, information is sent 
and received in a stream-like format in which the order of events is important. For example a player may not be allowed 
to interact after it has been "killed". The game server and the clients may be connected with a bi-directional stream 
protocol to ensure that events arrive in order. 

[0152] In a further embodiment, a system having WAP-based intelligent map/location measurement services may be 
25 provided. In this system, a location information stream is sent to a server which in turn sends back map and map co- 
ordinate data. If the location update is frequent, because the tracking is very fine (like tracking a car in a city or tracking 
a walker so that he or she can find a particular shop) bi-directional streams are used to preserve the order of the 
transactions. 

[0153] In yet afurther embodiment, the invention maybe used to access Internet-based multimedia applications. Such 
so applications generally use TCP streams for connecting to a client. If such an application (for example a RealAudio 
service) is to be connected to a WAP-enabled client, stream-like (sequence of messages) support in WAP can be used 
rather than attempting to convert stream-like TCP into transaction-oriented WTP. 

[0154] In still afurther embodiment, a voice-controlled WAP services may be provided which accepts voice commands 
and/or sends voice messages to a user. Voice recognition of a service-specified command set may be difficult to provide 
35 for a lightweight terminal in terms of processing power and weight. Using the invention voice data may be sent on an 
outgoing channel to a WAP server where sophisticated recognition/language selection can be accomplished. Similarly, 
a return channel can be used to convey sound/voice data as a response. 

[0155] The invention provides a new transaction class which can be used to provide an arbitrarily long sized sequence 
of messages within a single transaction. The invention is compatible with the WAP standard because in addition to the 

40 new features new transaction class 3 all the features of the WAP standard are kept. Class 3 transactions can be identified 
and handled separately. The ways in which errors, version and TIDs are handled is the same as in the WAP standard. 
[0156] In class 3 transactions, the message handling procedure also uses the existing segmentation and re-assembly 
process, and so no separate SAR process needs to be defined. However, it should be noted that the invention uses the 
existing segmentation and re-assembly procedure in two ways. It uses it in a way which is similar to that of class 2 in 

45 which messages are segmented in packets. In addition the invention also uses itto send a stream of messages irrespective 
of whether segmentation and re-assembly is being applied to a particular message. In either case, PSNs are always 
used. This is in contrast to class 2 transactions in which segmentation and re-assembly does not apply if there is only 
one packet. 

[0157] Although the invention is described in relation to WAP, it can be applied to any other transaction based com- 
50 munication protocol. For example it can be applied to browsing on IP networks. It is particularly suitable for wireless 
networks but may also be applied to wired networks. 

[0158] Particular implementations and embodiments of the invention have been described. It is clear to a person 
skilled in the art that the invention is not restricted to details of the embodiments presented above, but that it can be 
implemented in other embodiments using equivalent means without deviating from the characteristics of the invention. 
55 The scope of the invention is only restricted by the attached patent claims. 
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Claims 

1 . A method of carrying out a transaction over a link between a sender (2, 1 2) and a receiver (2, 1 2), 
the method comprising the steps of: 

5 

transmitting data in the form of a plurality of data messages each message representing a service data unit and 
comprising at least one data packet, 

receiving from the receiver acknowledgement of receipt of data packets so as to provide a reliable connection; 
notifying the receiver of the last data packet in each data message so as to indicate transmission of the corre- 
10 sponding service data units; and 

notifying the receiver of the last data message. 

2. A method of carrying out a transaction over a link between a sender (2, 1 2) and a receiver (2, 1 2), 
the method comprising the steps of: 

15 

receiving data in the form of a plurality of data messages each message representing a service data unit and 
comprising at least one data packet, 

the receiver acknowledging receipt of data packets so as to provide a reliable connection; 
the receiver being notified of the last data packet in each data message so as to indicate transmission of the 
20 corresponding service data units; and 

the receiver being notified of the last data message. 

3. A method according to claim 1 or claim 2 in which data is not of predetermined length. 

25 4. A method according to any preceding claim in which there is transmission of an arbitrarily long sized stream-like 
sequence of messages inside a transaction. 

5. A method according to any preceding claim in which the data packets are numbered consecutively by packets 
sequence numbers during transfer of the data. 

30 

6. A method according to claim 5 in which each message comprises packets having consecutive packet sequence 
numbers and the sequence of the packet sequence numbers continues from one message to the next message. 

7. A method according to any preceding claim in which each packet of the transaction has the same transaction identifier 

35 

8. A method according to any of claims 5 to 7 in which the packet sequence numbers wrap around. 

9. A method according to any preceding claim in which the data is segmented and re-assembled. 

40 10. A method according to any preceding claim in which communication between the sender and the receiver is bi- 
directional within the transaction. 

1 1 . A method according to claim 1 0 in which there are two channels provided, one for transmitting data from an initiator 
to a responder and the other for transmitting data in the opposite direction. 

45 

12. A method according to claim 1 1 in which at least one of the channels is closed by sending of the last message of 
the data. 

13. A method according to claim 1 1 or claim 12 in which the transaction is terminated if transmission over both channels 
50 is terminated. 

14. A method according to any preceding claim in which the packets are sent in groups of packets. 

15. A method according to claim 14 in which the receiver acknowledges a complete group when all packets from the 
55 group have been received. 

1 6. A method according to claim 1 5 in which the receiver acknowledges the last packet of a group when it has confirmed 
that the other packets of the group have been received. 
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17. A method according to any of claims 14 to 16 in which there can be outstanding packet groups in that packets of a 
subsequent group may be sent before an acknowledgement has been received for a previous group. 

1 8. A method according to any of claims 1 4 to 1 6 in which there cannot be outstanding packet groups. 

19. A method according to claim 18 in which a first message notifying of a missing packet is sent before a packet 
indicating the end of its packet group has been received. 

20. A method according to claim 19 in which a second message notifying of the missing packet is sent if the packet 
indicating the end of its packet group has been received and the missing packet has still not been received. 

21. A method according to any of claims 18 to 20 in which packets of a group are sent in transmission bursts and a 
packet notifying the completion of a particular group is notincluded in the transmission burst containing some packets 
of the particular group. 

22. A method according claim 21 in which the packet notifying the completion of a particular group is sent in a subsequent 
group. 

23. A method according claim 21 or claim 22 in which the packet notifying the completion of a particular group is only 
sent when an acknowledgement has been received for all of the packets of a previous group. 

24. A method according to any preceding claim which is a new transaction class having one reliable Invoke message 
and one reliable Result message, the Invoke and Result messages being conditionally expanded with reliable data 
messages. 

25. A method according to any preceding claim in which once the transaction has been started by an Invoke message, 
it is continued by Stream Data messages 

26. A method according to any preceding claim in which data transmission over one channel is terminated when the 
sender sends a TPI inidicating the end of data and it is received by the receiver. 

27. A method according to any preceding claim in which there is more than one transaction outstanding at any one time. 

28. A method according to any preceding claim in which there are a number of asynchronous transactions existing in 
a single session. 

29. A method according to any preceding claim in which the link is a wireless link (6). 

30. A method according to any preceding claim which occurs according to the Wireless Transaction Protocol Standard. 

31. A method according to any preceding claim in which the first message of the transaction is an Invoke PDU which 
comprises atransaction class parameterto indicate that the transaction comprises a data stream having an arbitrarily 
long length. 

32. A mobile terminal (2, 60) for transmitting data in the form of a plurality of data messages each message representing 
a service data unit and comprising at least one data packet the mobile terminal comprising an application contained 
in a memory and a protocol stack (68) the application and the protocol stack being capable of carrying out a transaction 
over a wireless link (6) between and the mobile terminal and a receiver (1 2) wherein the mobile terminal is capable 
of sending the messages to the receiver in a sequence, is capable of receiving from the receiver acknowledgement 
of receipt of the packets so as to provide a reliable connection, is capable of notifying the receiver of the last data 
packet in each data message so as to indicate transmission of the corresponding service data units, and is capable 
of notifying the receiver of the last data message. 

33. A gateway (12, 20) for transmitting data in the form of a plurality of data messages each message representing a 
service data unit and comprising at least one data packet the gateway comprising an application (26) contained in 
a memory and a protocol stack (28) the application and the protocol stack being capable of carrying out a transaction 
over a wireless link (6) between and the gateway and a receiver (2, 60) wherein the gateway is capable of sending 
the messages to the receiver in a sequence, is capable of receiving from the receiver acknowledgement of receipt 
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of the packets so as to provide a reliable connection, is capable of notifying the receiver of the last data packet in 
each data message so as to indicate transmission of the corresponding service data units, and is capable of notifying 
the receiver of the last data message. 

34. A data transmission system comprising at least one mobile terminal (2, 60), the mobile terminal comprising an 
application contained in a memory and a protocol stack (68) and being capable of receiving data in the form of a 
plurality of data messages, each message representing a service data unit and comprising at least one data packet, 
the application and the protocol stack of the mobile terminal being capable of carrying out a transaction over a 
wireless link (6) with a gateway (12, 20) wherein the gateway is capable of sending the messages to the mobile 
terminal in a sequence, the mobile terminal is capable of acknowledging receipt of the packets so as to provide a 
reliable connection, the gateway is capable of notifying the mobile terminal of the last data packet in each data 
message so as to indicate transmission of the corresponding service data units, and the gateway is capable of 
notifying the mobile terminal of the last data message. 

35. A data transmission system comprising at least one mobile terminal (2, 60), the mobile terminal comprising an 
application contained in a memory and a protocol stack (68) being capable of transmitting data in the form of a 
plurality of data messages, each data message representing a service data unit and comprising at least one data 
packet, the application and the protocol stack of the mobile terminal being capable of carrying out a transaction over 
a wireless link (6) with a gateway (12, 20) wherein the mobile terminal is capable of sending the messages to the 
gateway in a sequence, the gateway is capable of acknowledging receipt of the packets so as to provide a reliable 
connection, the mobile terminal is capable of notifying the gateway of the last data packet in each data message 
so as to indicate transmission of the corresponding service data units, and the mobile terminal is capable of notifying 
the gateway of the last data message. 

36. A computer program product stored on a computer readable medium the computer program product comprising: 

computer readable program means for causing a computer to carry out a transaction over a wireless link (6) 
between and a sender (2, 12) and a receiver (2, 12) the transaction comprising transmission data comprising 
a plurality of data messages each message representing a service data unit and comprising at least one data 
packet; 

computer readable program means for causing the sender to send the messages to the receiver in a sequence; 
computer readable program means enabling the sender to receive acknowledgement of receipt of packets so 
to provide a reliable connection; 

computer readable program means for causing the sender to notify the receiver of the last data packet in each 

data message so as to indicate transmission of the corresponding service data units; and 

computer readable program means for causing the sender to notify the receiver of the last data message. 

37. A computer program product stored on a computer readable medium the computer program product comprising: 

computer readable program means for causing a computer to carry out a transaction over a wireless link (6) 
between and a sender (2, 12) and a receiver (2, 12) the transaction comprising transmission data comprising 
a plurality of data messages each message representing a service data unit and comprising at least one data 
packet; 

computer readable program means for causing the receiver to receive the messages in a sequence; 
computer readable program means for causing the receiver to acknowledge receipt of packets so to provide a 
reliable connection; 

computer readable program means for causing the receiver to receive a notification of the last data packet in 

each data message so as to indicate transmission of the corresponding service data units; and 

computer readable program means for causing the receiver to receive a notification of the last data message. 
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